Configuration mechanism in hosted remote access environments

ABSTRACT

In the exemplary embodiments of the invention there is a method including setting up a first tunnel between a first device and a remote access relay, setting up a second tunnel between the remote access relay and a remote access server, and updating the first device with related parameters and settings on the remote access relay.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application claims priority under 35 U.S.C. §119(e) fromProvisional Patent Application No. 60/881,902, filed Jan. 23, 2007, thedisclosure of which is incorporated by reference herein in its entirety.

TECHNICAL FIELD

The teachings in accordance with the exemplary embodiments of thisinvention relate generally to a configuration mechanism in hosted remoteaccess environments. More particularly, the exemplary embodiments ofthis invention relate to configuration of the network connectivitybetween two or more universal plug and play (UPnP) devices when there isa remote access relay hosted by a third party.

BACKGROUND

This section is intended to provide a background or context to theinvention that is recited in the claims. The description herein mayinclude concepts that could be pursued, but are not necessarily onesthat have been previously conceived or pursued. Therefore, unlessotherwise indicated herein, what is described in this section is notprior art to the description and claims in this application and is notadmitted to be prior art by inclusion in this section.

UPnP technology (www.upnp.org) defines an architecture for pervasivepeer-to-peer network connectivity of UPnP devices, such as intelligentappliances, wireless devices, and PCs of all form factors. It defines afamily of protocols for automatically configuring devices, discoveringservices, and providing peer-to-peer data transfer over an IP network.UPnP technology is designed to bring easy-to-use, flexible,standards-based connectivity to ad-hoc or unmanaged networks, whether inhome, in a small business, public spaces, or attached to the Internet.It provides a distributed, open networking architecture that leveragesTCP/IP and the Web technologies to enable seamless proximity networkingin addition to control and data transfer among networked devices.

The UPnP Device Architecture (UDA), defined by UPnP forum and availablefrom the UPnP forum website, is designed to support zero-configuration,“invisible” networking, and automatic discovery for a breadth of devicecategories from a wide range of vendors. This means a device candynamically join a network, obtain an IP address, convey itscapabilities, and learn about the presence and capabilities of otherdevices.

A paper submitted within the UPnP Forum entitled “UPnP Remote AccessArchitecture draft v1.0”, defines Remote Access Architecture whichenables a remote UPnP device or UPnP Control point to connect to thehome network and to interact with the UPnP entities physically attachedto the home network. During this process it is expected that the remoteuser experiences the remote device behaving in a similar way as in thehome network.

Another paper submitted within the UPnP Forum entitled, “UPnP RemoteAccess Transport Agent (RATA) Config:1 Service”, defines a UPnP service(RATAConfig) that allows control points to provision and configure theparameters that are required for enabling a Remote Access Server (RAS)to accept and a remote Access Client (RAC) to initiate remote accessconnection.

A technical report entitled “DSL Forum TR-69, CPE Wide Area Network(WAN) Management Protocol,” is a specification describing the DSLcustomer premises equipment (CPE) WAN Management Protocol, intended forcommunication between a CPE and Auto-Configuration Server (ACS). The CPEWAN Management Protocol defines a mechanism that encompasses secureauto-configuration of a CPE, and also incorporates other CPE managementfunctions into a common framework.

The lack of available public Internet Protocol version 4 (IPv4)addresses is one of the reasons that the Internet Service Providers(ISPs) allocate private IPv4 addresses on the WAN interface of theirsubscriber's residential routers. This situation creates a problem forenabling Remote Access to UPnP home networks because this usage scenariorequires the residential gateway to be reachable from the publicinternet (e.g. public routable IP address on the WAN interface). Inorder to overcome this problem, there is a need for a third partynetwork element in the public Internet that allows the traffic from theRemote Access Client (RAC) to be relayed to the home Remote AccessServer (RAS).

However the third party network relay solution raises several challengesfrom the UPnP point of view because UPnP promises zero-configuration.First, a problem is presented in how to set up the secure transportchannels between the RAS, RAC and the RA Relay that is hosted in the ISPnetwork. Second, once these tunnels are up and running, a furtherproblem relates to how to allocate the network addresses (for example,IP addresses) so that the traffic can be routed between the RAC and thehome UPnP device in an UPnP Device Architecture (UDA) compatiblefashion. Accordingly, there is a need to define a new mechanism in theHosted Remote Access environments.

SUMMARY

In an exemplary aspect of the invention, there is a method comprisingsetting up a first tunnel between a first device and a remote accessrelay, setting up a second tunnel between the remote access relay and aremote access server, and updating the first device with relatedparameters and settings on the remote access relay.

In another exemplary aspect of the invention, there is a computerreadable medium encoded with a computer program executable by aprocessor to perform actions comprising setting up a first tunnelbetween a first device and a remote access relay, setting up a secondtunnel between the remote access relay and a remote access server, andupdating the first device with related parameters and settings on theremote access relay.

In yet another exemplary aspect of the invention, there is an apparatuscomprising a network interface, a memory, and a processor configured toset up a first tunnel between a first device and a remote access relay,the processor further configured to set up a second tunnel between theremote access relay and a remote access server, and the processorfurther configured to update the first device with related parametersand settings on the remote access relay.

In still another exemplary aspect of the invention, there is anapparatus comprising means for setting up a first tunnel between a firstdevice and a remote access relay, means for setting up a second tunnelbetween the remote access relay and a remote access server, and meansfor updating the first device with related parameters and settings onthe remote access relay.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other aspects of embodiments of this invention aremade more evident in the following Detailed Description, when read inconjunction with the attached Drawing Figures, wherein:

FIG. 1 shows is a diagram of an example Hosted Remote Accessenvironment;

FIG. 2 illustrates an example of how the secure tunnels are configured;

FIG. 3 illustrates an example of relay configuration message sequence;

FIG. 4 illustrates a Remote Access network elements roles in the addressallocation mechanism;

FIG. 5 illustrates a perspective view of a mobile phone for which theexemplary embodiments of this invention can be used;

FIG. 6 illustrates a schematic representation of the circuit of themobile phone in FIG. 5; and

FIG. 7 illustrates a method according to an exemplary embodiment of theinvention.

DETAILED DESCRIPTION

Various embodiments of the exemplary embodiments of this inventioncomprise a mechanism to setup the tunnels between the RAC, RAS and theRemote Access Relay hosted by the ISP and an address allocationmechanism that enable routing inside this overlay network in an UDAcompatible fashion.

FIG. 1 shows a diagram of an example Hosted Remote Access environmentwith hosted third party infrastructure. In such an environment, the RAC110 is able to connect to the RAS 120 only if the connection is mediatedby a Remote Access Relay (RAR) 130 hosted by the ISP (or another thirdparty). The reason for having this setup is because the RAS 120 does nothave a public IP address and therefore is not reachable from theInternet. So, in order to have RAC-RAS connectivity, two tunnels 140,150need to be established: one 140 from the RAC 110 to RAR 130 and anothertunnel 150 form the RAS 120 to RAR 130.

The paper entitled “UPnP Remote Access Architecture draft v1.0”describes the scenario where the RAC 110 connects directly to the RAS120 in the home network. In that scenario, the procedures forconfiguring the secure tunnels are described in the UPnP Remote AccessTransport Agent configuration paper mentioned above. However, neitherthe Remote Access Architecture draft nor the Remote Access TransportAgent configuration paper discusses the situation when the Remote Accessis mediated by the Remote Access Relay 130, as shown in FIG. 1. FIG. 1also depicts an Auto Configuration Server (ACS) 160, and UPnP device 155that is coupled through the RAS 120.

FIG. 2 shows an example of how the secure tunnels are configured. InFIG. 2, the connection between the RAC 110 and the UPnP device 155 isdone via two tunnels: a gateway-to-gateway tunnel 250 from the RAS 120to the RAR 130 and a client-to-gateway tunnel 240 from the RAC 110 tothe RAR 130. As compared to the UPnP Remote Access architecturedescribed above, this embodiment creates additional challenges, becausein order to make the experience “plug-and-play”, i.e.zero-configuration, there is a need to configure an additional tunnel250 between the RAS 220 and RAR 230 and to update the client withrelated parameters and settings on the RAR 130 so that the RAC device110 can initiate Remote Access connections.

The configuration of the RAS-RAR tunnel 250 can be performed by the autoconfiguration server 160. The configuration process depends on the typeof the infrastructure deployed in the ISP network. In the case ofDigital Subscribe Line (DSL), the Internet Service Provider canconfigure the RAR 130 and the RAS 120 by using as a baseline themechanisms defined in the TR-69 as described in the paper “DSL ForumTR-69, CPE Wide Area Network (WAN) Management Protocol.”

Each service in the UPnP device may contain any number of actions, eachaction having a set of input parameters and an optional return value.The action would include a name and possibly a set of arguments.Further, argument has a direction and the direction can be an input oran output, depending if the argument is passed into the action or if theargument is returned from the action to the caller. Further, there is areturn value that provides the result of the action.

For each UPnP service there can be a service type Uniform ResourceIdentifier (URI) that identifies the service. Further, there arestandard service types defined by a UPnP committee. For a service thereis a serviceId URI that identifies the particular service of a device'sservices. There can be no two services that share the same serviceId. Adevice type determines the services that a device may implement.

In addition, a service can also maintain variables that represent acurrent status of the service. It can be noted that a service may havezero or more such variables. Further, each state variable has a name, atype, a default value, and a current value. Each state variable also hasa set of allowed values that describe a range of permissible variablevalues, and state variables can trigger events upon state changes.

As described in the UPnP remote access transport agent paper and inaccordance with an exemplary embodiment of the invention state variablescan include string data type variables: RATAType,TransportAgentCapabilities, SupportedCredentialDelivery,CredentialsList, A_ARG_TYPE_ProfileList, A_ARG_TYPE_ProfileConfigInfo,StateVariableName1, and A_ARG_TYPE_StateVariableName3; and ui4 data typestate variable StateVariableName2.

Further, according to the UPnP remote access transport agent paper an“allowedValueList” for an RATAType state variable can include values“RAClient”, “RAServer”, “Value3”, and/or a vendor defined statevariable. Further, the “SupportedCredentialDelivery” and the“StateVariableName1” state variables can include “allowedValueList”values “Value1”, “Value2”, and “Value3”. In addition, according to theUPnP remote access transport agent paper an “allowedValueRange” for the“StateVariableName2” and the “A_ARG_TYPE_StateVariableName3” can include“Minimum value”, “Maximum value”, and “Increment”. It is further notedthat any of these values can be replaced with a vendor specific value.

However, in order to be able to configure this Remote Access specifictunnel 250, new data models need to be defined to support the servicesdefined by UPnP Remote Access Working Committee. For example, theconfiguration protocol used between the Auto Configuration Server 160and RAR 130, RAS 120 needs to be able to configure multiple types oftunnels, e.g. IPsec, Transport Layer Security (TLS)/Secure Socket Layer(SSL) as in Open VPN, etc.

In order to make the user experience similar as if the RAC 110 connectsdirectly to the RAS 120, the UPnP mechanisms defined in the UPnP RemoteAccess Architecture paper can be used. A Management Console (MC) 280,which is the collection of control points that are used to setup, manageand monitor the operations related to Remote Access, is able toconfigure the RAR 130 the same way as for RAS 120.

The Remote Access drafts in the UPnP Remote Access Architecture paperallows the MC 280 to configure the RAS 120 by indicating that the datastructures exchanged are of type server. In order to enable the MC 280to detect if the RAS 120 accepts connections via the RAR 130, a new RATAdata structure type relay can be used. One example of this new datastructure type can be expressed in XML, as shown below:

<?xml version=“1.0” encoding=“UTF-8”?> <RATADTxmlns=“urn:schemas-upnp-org:remoteaccess:ratadt”xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”xsi:schemaLocation=“urn:schemas-upnp-org:ra:ratadthttp://www.upnp.org/schemas/ra/ratadt-v0.1-20060926.xsd”><dataStructureType>relay</dataStructureType> <profileConfig> <profile><transportAgentName>transport name</transportAgentName><profileDescription>friendly description</profileDescription> </profile><profileData> <!--Placeholder for defining data specific for eachtransport mechanism. Data structures defined in another namespace--></profileData> </profileConfig> </RATADT>

The new relay data structure type is similar in some respects as tocontent and functionality with the server data structure type defined inthe “UPnP Remote Access Transport Agent (RATA) Config:1 Service” paper.However, and in accordance with exemplary embodiments of this invention,the effects of the configuration updates are seen on the RAR interfaceexposed to RAC 110 instead of the RAS 120. This difference can be seenin FIG. 3.

All changes applied on the Remote Accesses are propagated to the RAR 130through, for example, the same configuration protocol used forconfiguring the RAS-RAR tunnel 250.

In FIG. 2, the RAR 130 needs to handle the IP address allocation in sucha fashion that the RAC 110 has an IP address from the Home Networkaddress pool, and traffic from one tunnel is forwarded to the othertunnel. It is possible that the two tunnels 240, 250 do not use the sameenabling technology, e.g. one segment is provided by Open VirtualPrivate Network (VPN) and other by IP Security (IPSec), which is asecurity protocol from the Internet Engineering Task Force (IETF) thatprovides authentication and encryption over the internet. Therefore, thetunnels 240, 250 need to be configured in a “plug-and-play” fashion sothat the user is not required to be aware of the complexity of theunderlying architecture. Further, the IP addresses allocation needs toenable devices to communicate with each other in a UDA compatiblefashion.

The RAC 110 cannot directly acquire an IP address from the home DynamicHost Configuration Protocol (DHCP) server if the communication is donevia the RAR hosted by a third party (such as an ISP), instead it has torely on some functionality provided by the RAR 130. In one embodiment ofthis invention, RAR 130 acts as a DHCP relay agent and forwards the DHCPrequests received from the RAC 110 to the RAS 120. In another embodimentof this invention, DHCP server functionality exists in the RAR 130itself. If the DHCP server functionality exists in the RAR 130, the DHCPserver in both the RAR 130 and the RAS 120 needs to be properlyconfigured.

In one embodiment of this invention, the RAR 130 is acting as a DHCPrelay and it is configured to forward all DHCP requests coming from theRAC 110 to the RAS 120. This way the RAC 110 receives an IP address fromthe home IP address pool. The DHCP Relay Agent in RAR 130 and the DHCPServer in the RAS 120 are configured for Remote Access by the ISPConfiguration Server. If the ISP network is using DSL infrastructurethen the configuration protocol can be DSL Forum TR-69.

FIG. 4 shows another embodiment of this invention. In FIG. 4, the RAR430 is acting as a DHCP server and it directly provides the IP addressesfrom the home IP address pool. As shown in FIG. 4, this DHCP server/RAR430 may need a special address range. Whenever the DHCP server/RAR 430receives a DHCP request it allocates an IP address and then it notifiesthe ISP Auto Configuration Service (ACS) 470 (using, for example, anInform( ) function defined in TR-69 in the paper “DSL Forum TR-69, CPEWide Area Network(WAN) Management Protocol”). Then the ACS 470configures the home DHCP server/RAS 460 so that it adds the IP addressallocated to the RAC 410 to the reserved list of IP addresses (using,for example, a SetParameterValue/Attributes( ) function or an AddObject() function also defined in TR-69). Using the mechanisms defined in theDSL Forum TR-69 paper helps to keep the DHCP server/RAS 420 and DHCPserver/RAR 430 consistent so that no duplicate addresses are allocatedto two clients.

The embodiments of this invention create a framework that enables an ISPor a third party service provider to offer a mediation service thatenables remote access in situations where direct access is not possible.The foregoing description of address allocation mechanism uses thefunctions defined in the TR-69 paper as a non-limiting example for ahome network that is connected to the Internet via a DSL basedinfrastructure. For other network infrastructures (for example, a cablemodem based home network connected to the Internet) appropriateequivalent mechanisms can be used.

The DSL based embodiments of the exemplary embodiments of this inventionhave been presented for purposes of illustration and description and arenot intended to be exhaustive or to limit the present invention to theprecise form disclosed. It is understood that the mechanisms describedabove can be extended with data models for handling other Remote Accesssettings and parameters suitable for other network infrastructures (suchas cable modem based home network), in light of the above teachings oras may be acquired from practice of the exemplary embodiments of thisinvention.

The framework described above allows an end user to configure its remoteaccess device(s) regardless the access is direct to its home RAS ormediated by the RAR, hiding the complexity of the service providerinfrastructure. The RAS and RAR are configured using the same procedure,with the only difference being a new relay data structure flag thatindicates the configurations are updated on the RAR. Non-limiting andexemplary advantages that are gained by the use of the exemplaryembodiments of this invention include, but are not limited to:

-   a. Flexible way to support mediation from third party service    providers when it is not possible to connect directly to RAS.-   b. Enables the third party service provider to offer    advanced/management services to the end users, e.g. access control    management, trusted identity provider, etc.-   c. The setup process for the RAR-RAC interface and the existence of    a RAR on the communication path is transparent for the RAC, e.g. RAC    connects to RAR in the same way it connects directly to RAS.-   d. Third party service provider can host UPnP services in RAR that    are visible to the home UPnP devices as well as to remote UPnP    devices-   e. Simple and flexible architecture to support multiple access    networks infrastructure for the home network, e.g. DSL, cable, etc.-   f. Allows some restrictive operators to provide mediated remote    access solution for their end user so that they can provide added    value services for the RAS-RAR segment (e.g. QoS)

FIGS. 5 and 6 show one representative mobile phone 12 within which theexemplary embodiments of this invention may be implemented. It should beunderstood, however, that the exemplary embodiments of this inventionare not intended to be limited to one particular type of mobile phone 12or other electronic device such as a combination PDA, an integratedmessaging device (IMD), a desktop computer, or a notebook computer. Themobile phone 12 of FIGS. 5 and 6 is composed of various components thatmay include: a housing 30, a display 32, such as one in the form of aliquid crystal display, a keypad 34, a microphone 36, an ear-piece 38, abattery 40, an infrared port 42, an antenna 44, a smart card 46, a cardreader 48, radio interface circuit 52, codec circuit 54, a controller 56and a memory 58. These individual circuits and elements may all be of atype well known in the art. A high-speed serial interface may be used toimplement the communication between any two components in FIG. 6, forexample, between the controller 56 and display 32; between thecontroller 56 and codec 54, and/or between the codec 54 and the radiointerface 52.

In FIG. 7 there is illustrated a method according to an exemplaryembodiment of the invention where there is setting up a first tunnelbetween a first device and a remote access relay 710, setting up asecond tunnel between the remote access relay and a remote access server720, and updating the first device with related parameters and settingson the remote access relay 730.

Based on the foregoing it can be appreciated that in one aspect thereofthe exemplary embodiments of this invention provide a method comprisingsetting up a first tunnel between a first device and a remote accessrelay; setting up a second tunnel between the remote access relay and aremote access server; updating the first device with related parametersand settings on the remote access relay; wherein the remote accessserver is connected to a second device through a network.

In the method of the preceding paragraph, at least one of the firsttunnel and the second tunnel can be secure tunnels. Also, at least oneof the first device and the second device can be UPnP devices. Inaddition, the remote access relay can be provided by a third party.Further, the configuration process can be completed according to networkmanagement protocol specified in TR-69 by DSL Forum.

The method described in paragraphs can further comprise forwarding DHCPrequest from the first device to the remote access server.Alternatively, the method can further comprise providing an IP addressfor the first device and adding the IP address to a reserved list of IPaddresses for the network.

Based on the foregoing it can be appreciated that in another aspectthereof the exemplary embodiments of this invention provide a computerprogram product, embodied in a computer-readable medium, comprising:computer code for setting up a first tunnel between a first device and aremote access relay; computer code for setting up a second tunnelbetween the remote access relay and a remote access server; computercode for updating the first device with related parameters and settingson the remote access relay; wherein the remote access server isconnected to a second device through a network.

In the computer program product of the preceding paragraph, where atleast one of the first tunnel and the second tunnel can be securetunnels. Also, at least one of the first device and the second devicecan be UPnP devices. In addition, the remote access relay can beprovided by a third party. Further, the configuration process can becompleted according to network management protocol specified in TR-69 byDSL Forum.

The computer program product described in the preceding paragraphsfurther comprising computer code for forwarding DHCP request from thefirst device to the remote access server. Alternatively, the computerprogram product can further comprise computer code for providing an IPaddress for the first device and adding the IP address to a reservedlist of IP addresses for the network.

Based on the foregoing it can be appreciated that in a further aspectthereof the exemplary embodiments of this invention provide anelectronic device comprising: a processor; and a memory unitcommunicatively connected to the processor and including: executablecode for setting up a first tunnel between a first device and a remoteaccess relay; executable code for setting up a second tunnel between theremote access relay and a remote access server; executable code forupdating the first device with related parameters and settings on theremote access relay; wherein the remote access server is connected to asecond device through a network.

In the electronic device described in the preceding paragraph, at leastone of the first tunnel and the second tunnel can be secure tunnels.Also, at least one of the first device and the second device can be UPnPdevices. In addition, the remote access relay can be provided by a thirdparty. Further, the configuration process can be completed according tonetwork management protocol specified in TR-69 by DSL Forum.

The electronic device described in the preceding paragraphs can furthercomprise executable code for forwarding a DHCP request from the firstdevice to the remote access server. Alternatively, the computer programproduct can further comprise executable code for providing an IP addressfor the first device and adding the IP address to a reserved list of IPaddresses for the network.

Embodiments of the inventions may be practiced in various componentssuch as integrated circuit modules. The design of integrated circuits isby and large a highly automated process. Complex and powerful softwaretools are available for converting a logic level design into asemiconductor circuit design ready to be etched and formed on asemiconductor substrate.

Further, it is noted that devices including but not limited to the autoconfiguration server, the remote access client, the remote accessserver, the remote access relay, and the auto configuration server areor may be configurable and comprise suitable hardware and/or softwarefor communication and operation of the devices according to theexemplary embodiments or the invention. Such hardware can include but isnot limited to a wired or wireless receiver and/or transmitter, anetwork interface, and any other hardware, circuitry, and softwarenecessary to enable the exemplary embodiments of the invention.

Programs, such as those provided by Synopsys, Inc. of Mountain View,Calif. and Cadence Design, of San Jose, Calif. automatically routeconductors and locate components on a semiconductor chip using wellestablished rules of design as well as libraries of pre-stored designmodules. Once the design for a semiconductor circuit has been completed,the resultant design, in a standardized electronic format (e.g., Opus,GDSII, or the like) may be transmitted to a semiconductor fabricationfacility or “fab” for fabrication.

The foregoing description of the exemplary embodiments of the presentinvention has been presented for purposes of illustration anddescription. It is not intended to be exhaustive or to limit the presentinvention to the precise form disclosed, and modifications andvariations are possible in light of the above teachings or may beacquired from practice of the present invention. The embodiments werechosen and described in order to explain the principles of the presentinvention and its practical application to enable one skilled in the artto utilize the present invention in various embodiments and with variousmodifications as are suited to the particular use contemplated.

1. A method, comprising: setting up a first tunnel between a firstdevice and a remote access relay; setting up a second tunnel between theremote access relay and a remote access server; and updating the firstdevice with related parameters and settings on the remote access relay.2. The method of claim 1, where setting up the first tunnel comprisesconfiguration updates are applied to an interface of the remote accessrelay that is closest to the first device.
 3. The method of claim 2,where the configuration updates include a data structure type relayconfiguration.
 4. The method of claim 3, where the data structure typerelay configuration is expressed in extensible markup language (XML). 5.The method of claim 1, wherein after the first tunnel and the secondtunnel are set up the remote access server is connected to a seconddevice through the network.
 6. The method of claim 1, where at least oneof the first tunnel and the second tunnel is a secure tunnel.
 7. Themethod of claim 1, where at least one of the first device and the seconddevice are universal plug and play (UPnP) devices.
 8. The method ofclaim 1, where the remote access relay is operated by a third partydifferent from the first device and the remote access server.
 9. Themethod of claim 1, further comprising forwarding a dynamic hostconfiguration protocol (DHCP) request from the first device to theremote access server via the first and second tunnels.
 10. The method ofclaim 9, where the DHCP request is forwarded by the remote access relayfrom the first device to the remote access server.
 11. The method ofclaim 1, further comprising providing an internet protocol (IP) addressfor the first device and adding the IP address to a reserved list of IPaddresses for the network.
 12. The method of claim 1, where setting upthe first tunnel and setting up the second tunnel is transparent to auser of the first device.
 13. The method of claim 1 performed when thefirst device attempts a direct connection to the remote access server.14. The method of claim 1, where the remote access server can accept orreject setting up the tunnel.
 15. A computer readable medium encodedwith a computer program executable by a processor to perform actionscomprising: setting up a first tunnel between a first device and aremote access relay; setting up a second tunnel between the remoteaccess relay and a remote access server; and updating the first devicewith related parameters and settings on the remote access relay, whereinthe remote access server is connected to a second device through anetwork.
 16. An apparatus, comprising: a network interface; a memory;and a processor configured to set up a first tunnel between a firstdevice and a remote access relay; the processor further configured toset up a second tunnel between the remote access relay and a remoteaccess server; and the processor further configured to update the firstdevice with related parameters and settings on the remote access relay.17. The apparatus of claim 16, where setting up the first tunnelcomprises configuration updates are applied to an interface of theremote access relay that is closest to the first device.
 18. Theapparatus of claim 17, where the configuration updates include a datastructure type relay configuration.
 19. The apparatus of claim 18, wherethe data structure type relay configuration is expressed in extensiblemarkup language (XML).
 20. The apparatus of claim 16, wherein after thefirst tunnel and the second tunnel are set up the remote access serveris connected to a second device through the network.
 21. The apparatusof claim 16, where at least one of the first tunnel and the secondtunnel is a secure tunnel.
 22. The apparatus of claim 16, where at leastone of the first device and the second device are universal plug andplay (UPnP) devices.
 23. The apparatus of claim 16, where the remoteaccess relay is operated by a third party different from the firstdevice and the remote access server.
 24. The apparatus of claim 16,further comprising forwarding a dynamic host configuration protocol(DHCP) request from the first device to the remote access server via thefirst and second tunnels.
 25. The apparatus of claim 24, where the DHCPrequest is forwarded by the remote access relay from the first device tothe remote access server.
 26. The apparatus of claim 16, furthercomprising providing an internet protocol (IP) address for the firstdevice and adding the IP address to a reserved list of IP addresses forthe network.
 27. The apparatus of claim 16, where setting up the firsttunnel and setting up the second tunnel is transparent to a user of thefirst device.
 28. The apparatus of claim 16, where setting up the firsttunnel and setting up the second tunnel is performed when the firstdevice attempts a direct connection to the remote access server.
 29. Theapparatus of claim 16, where the remote access server can accept orreject setting up the tunnel.
 30. An apparatus, comprising: means forsetting up a first tunnel between a first device and a remote accessrelay; means for setting up a second tunnel between the remote accessrelay and a remote access server; and means for updating the firstdevice with related parameters and settings on the remote access relay.31. The apparatus of claim 24, where the means for setting up the firsttunnel, setting up the second tunnel, and updating the first devicecomprises a processor coupled to a memory and a network interface.